Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-058

Text File | 1995-06-07 | 65.1 KB | 1,887 lines | [TEXT/R*ch]

Received-Date: Thu, 15 Sep 1994 13:51:18 +0200
From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-058
To: [e-mail]
Date: Thu, 15 Sep 1994 13:51:12 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Errors-To: [e-mail]
Reply-To: [e-mail]
X-Sequence: 63

C.S.M.P. Digest             Thu, 15 Sep 94       Volume 3 : Issue 58

Today's Topics:

        AppleEvents for command line args (argc, argv)?
        Exception Handling
        NIM on develop, as of 19
        Need to Stop flashing Desktop when changing palletes
        PPostEvent mouse events
        Sample MacTcp Programs
        Selecting Window via menus
        SetDialogDefaultItem real?
        Stack sniffer - how can I turn it off?



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users.  To search back issues
with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.


-------------------------------------------------------

>From [e-mail] (Ron Nicholson)
Subject: AppleEvents for command line args (argc, argv)?
Date: Wed, 24 Aug 1994 18:05:15 GMT
Organization: Silicon Graphics, Inc., Mountain View, CA

Are there AppleEvents suitable for passing a unix style command line
to a ported Unix C application?  I handle the 4 required AppleEvents
in a wrapper, but that's not enough to pass all the args needed to
a ported app.

Thanks,

Ronald H. Nicholson, Jr.    [e-mail], [e-mail], N6YWU
#include <canonical.disclaimer>     // I speak only for myself, etc.

+++++++++++++++++++++++++++

>From [e-mail] (Ron Nicholson)
Date: Thu, 1 Sep 1994 05:51:04 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

In article <[e-mail]> I wrote:
>Are there AppleEvents suitable for passing a unix style command line
>to a ported Unix C application?  I handle the 4 required AppleEvents
>in a wrapper, but that's not enough to pass all the args needed to
>a ported app.

Thanks for all the replies.  Several people recommended using the
DoScript ('dosc') command, part of the misc suite.  I tried using the
DoScript command and it works just fine.

Inside my initialization code for the required handlers I added:

    err = AEInstallEventHandler('misc', kAEDoScript,
                NewAEEventHandlerProc(myHandleDoScript), 0, false);

// 'misc' == kAEMiscSuite ; couldn't find it in my headers files.

Inside the myHandleDoScript AE handler routine I used:

    err = AEGetParamPtr(aevt, keyDirectObject, typeChar,
                &typeCode, myParamTextBuffer, 256L, &actualSize);

This puts a string of text into myParamTextBuffer that can be parsed
into parameters or commands (in the main loop, NOT in the handler).

Do I need to do anything else to make this bulletproof?

I needed an aete resource containing DoScript and the required
AppleEvents.  I found one inside the ToolServer 1.1 application.  I
just copied it since I don't have an aete editor.

I'm going to try this for porting standalone unix filters like grep.
>>> Tell application "grep" to DoScript "grep -i foo somefile.txt"
Something like "grep bar < infile > outfile" should work for unix style
file names in a default directory.  I suppose something like this could
be packaged up with a dropshell to make it a scriptshell.

- -
Ronald H. Nicholson, Jr.    [e-mail], [e-mail], N6YWU
#include <canonical.disclaimer>     // I speak only for myself, etc.


---------------------------

>From [e-mail] (Aaron Starr)
Subject: Exception Handling
Date: 29 Aug 1994 18:58:11 GMT
Organization: College of Engineering, Oregon State University


Until we have a compiler that supports exception handling, I need to use
some sort of approximation in my code.  Anyone have any preferences?

I know that Symantec has an exception library for TCL, as well as a
Bedrock exception library, and I know that Metrowerks has something
similar for PowerPlant.  Does anyone know which of these is most similar
to likely implementations in the compiler?

Thanks for info,

Aaron Starr
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (AFC JLloyd)
Date: 30 Aug 1994 02:59:30 -0400
Organization: America Online, Inc. (1-800-827-6364)

Aaron Starr ([e-mail] ) writes:

>Until we have a compiler that supports exception handling, I need to use
>some sort of approximation in my code.  Anyone have any preferences?
>
>I know that Symantec has an exception library for TCL, as well as a
>Bedrock exception library, and I know that Metrowerks has something
>similar for PowerPlant.  Does anyone know which of these is most similar
>to likely implementations in the compiler?

I'm the engineer who did most of the work on BEL.  If your criteria is
compatibility to the C++ standard, then I think BEL is your best choice.
Of course, I'm biased, but let me try to give you enough facts so that you
can make an objective decision.

The original TCL exception handling implementation made no attempt to
throw/catch objects, and no attempt to delete stack-based objects as the
stack is unwound.

The PowerPlant mechanism does not throw objects, though it does delete
stack-based objects.  However, it calls constructors for partially
constructed objects, and doesn't prevent memory leaks when exceptions are
thrown from constructors of objects that are being allocated from the
heap.

BEL does throw/catch objects; in fact, BEL only throws objects.  It
doesn't allow throwing of arbitrary types like integers and strings.  Of
course, you can package integers and strings inside exception classes of
your own design.

BEL properly deletes stack based objects as the stack is unwound.
Destructors are called only for fully constructed objects.  However, BEL
doesn't do this automatically; you must insert a macro call at the end of
every constructor and the start of every destructor for the classes that
need automatic cleanup.  You must also derive such classes from a special
class.  If you use multiple inheritance there are some restrictions; the
major one being that you can't inherit from the special "CAutoDestruct"
class more than once, and virtual base classes are not supported.  If you
use mixin style inheritance, then your mixin classes should not be derived
from CAutoDestruct.

BEL also handles the case where an object is allocated from the heap using
operator new and an exception is thrown from the constructor.  In this
case, the raw memory allocated (with ::operator new()) must be deleted by
the exception handling mechanism.

The BEL macros that implement the programming interface are designed to be
compatible with the C++ exception handling syntax.  When compilers provide
exception handling, BEL's macros can be redefined to the C++ syntax.  You
can then recompile your code without making any changes to take advantage
of the compilers support.  Of course, you can then globally replace the
macros with the real syntax, but there may be good reasons to continue
using the macros for a while.   For example, an implementation of BEL for
Windows exists, so if you write cross platform code using BEL you will
want to wait to use the true C++ syntax until all of your compilers
support exceptions (and do so relatively bug-free).

Finally, even though Bedrock is no more, the OpenDoc Parts Framework (OPF)
is being developed with BEL.  I am now a contractor at Apple working on
OPF, and I am enhancing BEL as part of the contract.

What is the downside to BEL?  The main issue is performance and code size.
 There are lots of things a compiler can do that can't be done using
portable C++ code; that is why Stroustrup wanted exceptions in the
language, and not just a part of the standard library.  You'll have to
settle with some overhead until the compilers implement exceptions.  There
are of course other compromises.

Jim Lloyd
[e-mail]  -or- [e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Jonathan Hess)
Date: 30 Aug 1994 18:53:50 GMT
Organization: ViviStar Consulting

In article <33tb43$[e-mail]>
[e-mail] (Aaron Starr) writes:

> I know that Symantec has an exception library for TCL, as well as a
> Bedrock exception library, and I know that Metrowerks has something
> similar for PowerPlant.  Does anyone know which of these is most similar
> to likely implementations in the compiler?

TCL 2 uses the Bedrock exception library "BEL."  Once you get past the
macros, BEL probably is closer to C++ exceptions for throwing actual
objects and the like.

But, if you like simplicity, UExceptions from PowerPlant is REAL clean.

In both cases you'll probably be able to global GREP search and
replaces for C++ exceptions.

As for my personal preference... well I'm biased.   :)

, Jonathan Hess
Metrowerks, Inc.
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (AFC JLloyd)
Date: 31 Aug 1994 03:16:03 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <33vv7u$[e-mail]>, [e-mail] (Jonathan
Hess) writes:

>In article <33tb43$[e-mail]>
>[e-mail] (Aaron Starr) writes:
>
>> I know that Symantec has an exception library for TCL, as well as a
>> Bedrock exception library, and I know that Metrowerks has something
>> similar for PowerPlant.  Does anyone know which of these is most
similar
>> to likely implementations in the compiler?
>
>TCL 2 uses the Bedrock exception library "BEL."  Once you get past the
>macros, BEL probably is closer to C++ exceptions for throwing actual
>objects and the like.
>
>But, if you like simplicity, UExceptions from PowerPlant is REAL clean.
>
>In both cases you'll probably be able to global GREP search and
>replaces for C++ exceptions.
>
>As for my personal preference... well I'm biased.   :)

The number one design criteria for BEL was to be "sufficiently" close to
the C++ standard.  To achieve this we wanted application developers to be
able to write exception handling code in almost exactly the same style
they would use with C++ exceptions, with only minimal restrictions, and
that code written using BEL could be recompiled without changes and work
correctly when compilers support C++ exceptions.

Alas, this criteria often precluded simplicity.

As it happens, I spend a little of my spare time working on an idea I have
for an educational game.  The exception library I wrote for it is even
simpler than PowerPlant's UExceptions.  You see, I too believe that for
some applications, simplicity is more important than adherence to some
external standard.

Jim Lloyd
[e-mail] -or- [e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Sean Parent)
Date: Wed, 31 Aug 1994 20:49:22 GMT
Organization: Adobe Systems Incorporated

How does BEL handle the case of an auto-destruct member within another
auto-destruct derived class? That is, how do you handle:

class CFoo : CAutoDestruct {
   ...
}
class CBar : CAutoDestruct {
   CFoo  fooMember;
}

void Test {
   CBar bar;
   CFoo foo;
   Failure(); // or throw
}

You need to thread foo and bar onto your exception stack but not fooMember
(since it's destructor will get called when bar is destructed).

Sean

In article <341anj$[e-mail]>, [e-mail] (AFC
JLloyd) wrote:

> In article <33vv7u$[e-mail]>, [e-mail] (Jonathan
> Hess) writes:
>
> >In article <33tb43$[e-mail]>
> >[e-mail] (Aaron Starr) writes:
> >
> >> I know that Symantec has an exception library for TCL, as well as a
> >> Bedrock exception library, and I know that Metrowerks has something
> >> similar for PowerPlant.  Does anyone know which of these is most
> similar
> >> to likely implementations in the compiler?
> >
> >TCL 2 uses the Bedrock exception library "BEL."  Once you get past the
> >macros, BEL probably is closer to C++ exceptions for throwing actual
> >objects and the like.
> >
> >But, if you like simplicity, UExceptions from PowerPlant is REAL clean.
> >
> >In both cases you'll probably be able to global GREP search and
> >replaces for C++ exceptions.
> >
> >As for my personal preference... well I'm biased.   :)
>
> The number one design criteria for BEL was to be "sufficiently" close to
> the C++ standard.  To achieve this we wanted application developers to be
> able to write exception handling code in almost exactly the same style
> they would use with C++ exceptions, with only minimal restrictions, and
> that code written using BEL could be recompiled without changes and work
> correctly when compilers support C++ exceptions.
>
> Alas, this criteria often precluded simplicity.
>
> As it happens, I spend a little of my spare time working on an idea I have
> for an educational game.  The exception library I wrote for it is even
> simpler than PowerPlant's UExceptions.  You see, I too believe that for
> some applications, simplicity is more important than adherence to some
> external standard.
>
> Jim Lloyd
> [e-mail] -or- [e-mail]

--
Sean Parent
[e-mail]
"The critical driver of every successful project is its focused ruthlessness."
        Grady Booch

+++++++++++++++++++++++++++

>From [e-mail] (ObjFactory)
Date: 1 Sep 1994 16:48:03 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>,
[e-mail] (Sean Parent) writes:

>How does BEL handle the case of an auto-destruct member within another
>auto-destruct derived class? That is, how do you handle:

>class CFoo : CAutoDestruct {
>   ...
>}
>class CBar : CAutoDestruct {
>   CFoo  fooMember;
>}

>void Test {
>   CBar bar;
>   CFoo foo;
>   Failure(); // or throw
>}

>You need to thread foo and bar onto your exception stack but not
fooMember
>(since it's destructor will get called when bar is destructed).

You seem to have answered your own question. :)

Bob Foster
Object Factory

+++++++++++++++++++++++++++

>From [e-mail] (AFC JLloyd)
Date: 1 Sep 1994 18:13:09 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <345em3$[e-mail]>, [e-mail]
(ObjFactory) writes:

>In article <[e-mail]>,
>[e-mail] (Sean Parent) writes:
>
>>How does BEL handle the case of an auto-destruct member within another
>>auto-destruct derived class? That is, how do you handle:
>
>>class CFoo : CAutoDestruct {
>>   ...
>>}
>>class CBar : CAutoDestruct {
>>   CFoo  fooMember;
>>}
>
>>void Test {
>>   CBar bar;
>>   CFoo foo;
>>   Failure(); // or throw
>>}
>
>>You need to thread foo and bar onto your exception stack but not
>fooMember
>>(since it's destructor will get called when bar is destructed).
>
>You seem to have answered your own question. :)
>
>Bob Foster
>Object Factory

No, BEL threads all three objects on the delete stack, but Sean's
assumption that the fooMember is on the top of the stack is incorrect --
subobjects are constructed before their owning object.  So, the stack
order at the time of failure is:

bar.fooMember; bar; foo;

BEL first calls foo.CFoo::~CFoo(), then calls bar.CBar::~CBar.  The
destructor of CBar implicitly calls the destructor
bar.fooMember.CFoo::~CFoo().  Inside this destructor is the
START_DESTRUCTOR macro, which informs BEL to pop the deletestack entry for
bar.fooMember.  When the destructor returns to BEL, the delete stack is
now empty, so BEL doesn't try to delete bar.fooMember.

This strategy results in more items being placed onto the delete stack
than is theoretically necessary, but less computation at runtime to
determine if an entry should be pushed onto the stack or not.  We
therefore have traded off a little extra storage for faster code.

Jim Lloyd - AFC JLloyd


---------------------------

>From [e-mail] ( nick.c )
Subject: NIM on develop, as of 19
Date: Wed, 31 Aug 94 14:50:26 GMT
Organization: The Pitt, Chemistry


Folks:

    Someone was asking about the new NIM policy for _develop_, and what
      volumes would be on 19 that weren't on 18.  Just got 19, and noticed
      the absense of the Old IM and beta QD GX books, but they added as
      "specials" Sound and Imaging with Quickdraw.  Here's a running
      index of NIM I'm keeping for my own use, with 19 added.
      If you have issue 17 and up you have 15 of the NIM, with 7 (beta)
      QD GX books, the Human Interface guidelines and Old IM VI.

    BTW, I saw a CD at the bookstore with the Human Interface Guidelines
      and _Making it Macintosh_ on one CD for $49.  Anyone checked this
      out?  There has got to be more on it that just that, but the package
      wasn't very helpfull.

                                        -- nick



develop NIM Index:
~~~~~~~~~~~~~~~~~~

volume 17: (last "comprehensive")
=================================

  NIM (presume "core")
    Toolbox Essentials
    More Mac Toolbox
    Memory
    Files

  NIM (unique this CD)
    Overview
    Processes
    Devices (Preview)
    Interapplication Comm
    QuickTime
    QuickTime Components
    Text

  QD GX 1.0b3 <- Note beta
    Environment & Utilities
    Extensions & Drivers
    Functin Index
    Graphics
    Objects
    Printing
    Typography

  Misc.
    Human Interface Guidelines
    Old IM volume VI


volume 18: (first "reduced")
============================

  NIM (presume "core")
    Toolbox Essentials
    More Mac Toolbox
    Memory
    Files

  NIM (unique this CD)
    PowerPC Numerics
    PowerPC System Software

  QD GX b3 <- Note beta
    Environment & Utilities
    Extensions & Drivers
    Functin Index
    Graphics
    Objects
    Printing
    Typography

  Misc.
    Human Interface Guidelines
    Old IM volume VI


volume 19: (second "reduced")
=============================

  NIM (presume "core")
    Toolbox Essentials
    More Mac Toolbox
    Memory
    Files

  NIM (unique this CD)
    Imaging With Quickdraw
    Sound

  Misc.
    Human Interface Guidelines


The README explanation of new NIM policy:
=========================================

Why aren't all of the volumes of New Inside Macintosh on this
issue of the Bookmark CD?

Later this year, Apple and Addison-Wesley will release the
New Inside Macintosh (NIM) CD.  The NIM CD will offer all
Inside Macintosh volumes to date in Apple DocViewer format,
a complete cross reference, and numerous prebuilt DocViewer
collections to allow easy querying across the information.
All of the NIM books, if purchased separately, would cost
several hundred dollars. The complete electronic set,
however, will be offered at the introductory price of $99
(suggested retail price).

To avoid conflicts, the introduction of this product has
caused us to alter our practice of providing all NIM volumes
on the Bookmark CD.  Because the low subscription price for
develop and the Bookmark cannot support the necessary
enhancements, updates, and wider distribution of the
electronic NIM product, we've had to make some concessions.
The initial plan was to simply remove all NIM content from
the Bookmark CD.  We realize, however, that this content is
extremely important to a great many of you and that it is
necessary for your development projects.

So, we've compromised a bit - beginning with this CD, the
Bookmark will include a core set of NIM volumes.
Additionally, each issue of the Bookmark CD will feature
other volumes of NIM.  The core set will stay fairly
consistent, but the featured volumes will change on each
subsequent issue of the Bookmark CD.

While this solution may not be optimal for all develop
subscribers, it was a compromise that was necessary to make.
 We hope, of course, that you feel that develop and the
other content on the Bookmark CD is well worth the low
subscription price.

Sincerely,
The develop and Bookmark CD team

- -



                                    _/   _/  _/  _/_/_/   _/   _/
     Interet: [e-mail]        _/_/ _/  _/  _/   _/  _/_/_/
      eWorld: nick                _/ _/_/  _/  _/       _/ _/
         CIS: 71232,766          _/   _/  _/   _/_/_/  _/   _/


+++++++++++++++++++++++++++

>From [e-mail] ( nick.c )
Date: Wed, 31 Aug 94 15:15:54 GMT
Organization: The Pitt, Chemistry



    This might be more usefull.

                        -- nick

- -


develop NIM Index:
~~~~~~~~~~~~~~~~~~

    NIM: Toolbox Essentials             ANY develop (17up)
    NIM: More Mac Toolbox               ANY develop (17up)
    NIM: Memory                         ANY develop (17up)
    NIM: Files                          ANY develop (17up)

    NIM: Overview                       17  develop
    NIM: Processes                      17  develop
    NIM: Devices (Preview)              17  develop
    NIM: Interapplication Comm          17  develop
    NIM: QuickTime                      17  develop
    NIM: QuickTime Components           17  develop
    NIM: Text                           17  develop

    NIM: Imaging With Quickdraw         19  develop
    NIM: Sound                          19  develop

    NIM: PowerPC Numerics               18  develop
    NIM: PowerPC System Software        18  develop ___ 15 volumes

    NIM: QD/GX Environment & Utilities  17 or 18 develop
    NIM: QD/GX Extensions & Drivers     17 or 18 develop
    NIM: QD/GX Functin Index            17 or 18 develop
    NIM: QD/GX Graphics                 17 or 18 develop
    NIM: QD/GX Objects                  17 or 18 develop
    NIM: QD/GX Printing                 17 or 18 develop
    NIM: QD/GX Typography               17 or 18 develop ___ 7 volumes

    Human Interface Guidelines          ANY develop (17up)
    Old IM volume VI                    17 or 18 develop



                                    _/   _/  _/  _/_/_/   _/   _/
     Interet: [e-mail]        _/_/ _/  _/  _/   _/  _/_/_/
      eWorld: nick                _/ _/_/  _/  _/       _/ _/
         CIS: 71232,766          _/   _/  _/   _/_/_/  _/   _/


---------------------------

>From [e-mail] (J. Fletcher)
Subject: Need to Stop flashing Desktop when changing palletes
Date: Tue, 30 Aug 1994 18:28:53 GMT
Organization: University of Manchester, UK


I'm writing a small database application which displays 256 colour
picts in a window. As I swap in different pictures, I set a new
optimised pallette to get the best colour scheme possible.

The problem is that every time a set a new palatte, everything
flashes all over the place, scroll bars, desktop pattern etc.

What steps can I use to minimise these visual irritations?

I've got some ideas but does Anybody have any ideas on how to
implement the following :-

1) Get the Desktop pattern, save it, Set it to a black/white
checkerboard 'grey' ands restore at app. quit time.

2) Force all screen windows to display their window bar/controls
in neat black/white (like setting to black/white only in monitors
CP) yet allowing colour drawing.

Julian
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (RadixInc)
Date: 30 Aug 1994 18:34:01 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, [e-mail]
(J. Fletcher) writes:

<<The problem is that every time a set a new palatte, everything
flashes all over the place, scroll bars, desktop pattern etc.

What steps can I use to minimise these visual irritations?

I've got some ideas but does Anybody have any ideas on how to
implement the following :-

1) Get the Desktop pattern, save it, Set it to a black/white
checkerboard 'grey' ands restore at app. quit time.

2) Force all screen windows to display their window bar/controls
in neat black/white (like setting to black/white only in monitors
CP) yet allowing colour drawing.>>

The problem is inherent in the way the Pallette Manager and color devices
work. The video card for each device has a table with and RGB entry for
each color entry--there are 256 of them on an 8-bit card. When you change
pallettes the Pallette Manager tries to keep everything in order, but if
there aren't enough available (unused) colors in the color table it has to
remap some colors, and that's when you get the flash and weird colors.

Both of the solutions you propose are, in my opinion, worse than the
problem. You would be making changes that affect other programs, and there
is no way to tell what that will do to them. Fiddling with the desktop
pattern is not a good idea; that should be under the user's control. And
how would you force other apps to get only B&W controls without installing
a patch at startup time? Also what will you do when your app is switched
out--flip everything back? That will cause more flashing than the pallette
problem.

If you can't use the System Pallette, you'll have to live with the colors
flashing.

Gregory Jorgensen
Radix Consulting Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Mark Hanrek)
Date: 31 Aug 1994 09:19:24 GMT
Organization: The Information Workshop

> In article <[e-mail]>, [e-mail]
> (J. Fletcher) writes:
>
> <<The problem is that every time a set a new palatte, everything
> flashes all over the place, scroll bars, desktop pattern etc.

The problem is that we've forgotten that "the flash" is the tradeoff we
had accepted for the benefit of being able to use custom color tables,
which usually yield stunning color accuracy and realism for a 256-color
system.

There are "ways" to minimize the effects.

* Use a gamma fader to fade down the monitor between pictures to hide the flash.

* Utilize a "backdrop window" with a gray pattern (alternate black and
white pixels) to hide the desktop and other application's windows, since
black and white are always in every custom color table, and will not
flash.

* Use a black backdrop which is traditional with the "slide show" options
of most graphics applications.

* Always make sure the display window is full screen.

* Always create greedy palettes with all hte entries always set to
pmTolerant + pmExplicity and a tolerance of zero, so that all other
applications and the Finder are forced to black and white mode.

Hopefully one of these suggestions will help.

There are only 256 colors available in the hardware, and that's it.


Mark Hanrek

+++++++++++++++++++++++++++

>From [e-mail] (CarlF2)
Date: 31 Aug 1994 09:45:08 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, [e-mail]
(J. Fletcher) writes:

>I'm writing a small database application which displays 256 colour
>picts in a window. As I swap in different pictures, I set a new
>optimised pallette to get the best colour scheme possible.

>The problem is that every time a set a new palatte, everything
>flashes all over the place, scroll bars, desktop pattern etc.

>......[deleted]

Try using a single animated palette for your application, with every entry
but black and white reserved for your application. (This will force the
background applications to use B&W; if you can, you might leave some other
entries for them to use as well.) Then when you want to change your
colors, use AnimatePalette. Since no other application is using those
entries, no flash will occur.

Carl Fristrom
Medfield MA

---------------------------

>From [e-mail] (Bill Stackhouse)
Subject: PPostEvent mouse events
Date: 26 Aug 1994 20:25:24 GMT
Organization: Informix Software, Inc.

I am trying to post mouseUp and mouseDown events to my application
using PPostEvent. After call PPostEvent, the what field is set to
-1. The return value is 0. If I scan the event queue, there are
no events. Even though I set the mouse position using low mem
globals before the post, the where field has a different value
than where the mouse is.

What does it take to post mouse events?

Thanks
Bill

+++++++++++++++++++++++++++

>From [e-mail] (Pace Bonner)
Date: 29 Aug 1994 18:01:19 GMT
Organization: PB Computing

In article <33lj3k$[e-mail]>, [e-mail] (Bill
Stackhouse) wrote:

> I am trying to post mouseUp and mouseDown events to my application
> using PPostEvent. After call PPostEvent, the what field is set to
> -1. The return value is 0. If I scan the event queue, there are
> no events. Even though I set the mouse position using low mem
> globals before the post, the where field has a different value
> than where the mouse is.
>
> What does it take to post mouse events?

Try this code....It works for me.

        /* do a mouse down with correct cmd keys */
void MakeMouse(where,Mods)
Point             where;
short             Mods;
{
    EvQEl            *MyEventPtr;
    OsErr            err;

    err = PPostEvent(mouseDown, 0, &MyEventPtr);
    MyEventPtr->evtQWhere.h = where.h;
    MyEventPtr->evtQWhere.v = where.v;
    MyEventPtr->evtQModifiers = Mods;

    err = PPostEvent(mouseUp, 0, &MyEventPtr);
    MyEventPtr->evtQWhere.h = where.h;
    MyEventPtr->evtQWhere.v = where.v;
    MyEventPtr->evtQModifiers = Mods;

}

+------------------------------------------------------------------------+
Pace Bonner                Macintosh & Newton        512.335.1033
PB Computing              Software Development       11100 Spear Oak Cove
[e-mail]         Services             Austin, TX 78759-7004
+------------------------------------------------------------------------+

+++++++++++++++++++++++++++

>From [e-mail] (Keith Rollin)
Date: Thu, 01 Sep 1994 19:42:04 -0800
Organization: Apple ][ -> Mac -> Taligent -> Newton -> Windows?

In article <33lj3k$[e-mail]>, [e-mail] (Bill
Stackhouse) wrote:

>I am trying to post mouseUp and mouseDown events to my application
>using PPostEvent. After call PPostEvent, the what field is set to
>-1. The return value is 0. If I scan the event queue, there are
>no events. Even though I set the mouse position using low mem
>globals before the post, the where field has a different value
>than where the mouse is.
>
>What does it take to post mouse events?

This is the way I did it for Macintosh Programming Secrets:

                PPostEvent(mouseDown, 0, &qElPtr);
                qElPtr->evtQWhere = location;
                PPostEvent(mouseUp, 0, &qElPtr);
                qElPtr->evtQWhere = location;

This code has always worked for me so far. I don't know if there are any
A/UX issues.

- --------------------------------------------------------------------------
Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team Newton

---------------------------

>From [e-mail] (Jeff Dunning)
Subject: Sample MacTcp Programs
Date: Wed, 31 Aug 94 18:49:44 GMT
Organization: Los Alamos National lab.

I am looking for a couple of sample MacTcp programs. Where might some be found.

Thanks.
[e-mail]
Jeff Dunning
Los Alamos National Laboratory
[phone]

+++++++++++++++++++++++++++

>From [e-mail] (Mark Hanrek)
Date: 31 Aug 1994 20:52:10 GMT
Organization: The Information Workshop

In article <[e-mail]>, [e-mail] wrote:

> I am looking for a couple of sample MacTcp programs.
> Where might some be found?


Jeff,

Here are some leads to resources...


  * Snippets/network section of Developer CD

  * Snippets section of ftp://ftp.apple.com/

  * ftp://seeding.apple.com/mactcp/MacTCP_Dev_Kit

  * articles in "develop" magazine ftp://ftp.apple.com

  * source code archives everywhere
      ( start at nic.switch.ch )


This should help. :)

Mark Hanrek

+++++++++++++++++++++++++++

>From [e-mail] (Pete Resnick)
Date: Wed, 31 Aug 1994 18:16:38 -0500
Organization: University of Illinois at Urbana-Champaign

In article <[e-mail]>, [e-mail] (Mark
Hanrek) wrote:

>In article <[e-mail]>, [e-mail] wrote:
>
>> I am looking for a couple of sample MacTcp programs.
>> Where might some be found?
>
>Here are some leads to resources...
>
>
>  * Snippets/network section of Developer CD
>
>  * Snippets section of ftp://ftp.apple.com/

Eeeek!!! No, don't use those as examples. They're horribly written,
useless pieces of code. They do synchronous I/O that will hang your
machine. Just say no!

>  * ftp://seeding.apple.com/mactcp/MacTCP_Dev_Kit

I don't believe there is any code in there.

>  * articles in "develop" magazine ftp://ftp.apple.com

Don't look at the articles by Steve Falkenburg. Same warning as above on
Snippets.

>  * source code archives everywhere
>      ( start at nic.switch.ch )

Also look at the NewsWatcher source code--

ftp://ftp.acns.nwu.edu//pub/newswatcher/source-20b9.sea.hqx

And some of Peter Lewis's stuff (which should be lots of places).

pr
--
Pete Resnick        (...so what is a mojo, and why would one be rising?)
Doctoral Student - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

---------------------------

>From [e-mail] (Jeff Beeghly)
Subject: Selecting Window via menus
Date: 31 Aug 1994 17:37:50 GMT
Organization: University of Washington


I'm creating an app that will contain multiple windows that are
dynamically created and destroyed.  I was keeping track of each window
and it's data via a linked-list, but some friends of mine said that the
"Mac way of handling multiple child windows is to use window reference
values".


So I converted my app from using linked-lists to using window references
(not an easy task, mind you) and I'm finding out that this method has
several setbacks compared to my original method, one of which is bringing
a window to the front via menus.

I was digging through THINK Reference and I found out that a Window
Record contains a pointer to the next window.  Well, I implemented a test
into my program that displays the title of each child window:

i = 0;
whichWindow = FrontWindow();
while( whichWindow )
{
    GetWTitle(whichWindow, title);
    MoveTo(4, 10 + i);
    DrawString(title);
    whichWindow = (WindowPtr )(((WindowPeek )whichWindow)->nextWindow);
    i += 20;
}

I'm comming across 2 problems with this:
1) In my app, if I create 4 new windows, then invoke this operation, only
the top window's (window #4) title is displayed.  However, if I click on
one of the other windows (causing the window to be moved to the front),
then invoke this function, all four titles appear.  Thus, if I was to use
this implementation of getting a list of windows, it wouldn't be valid
until one of the windows was topped.

2) Even when the items are displayed, they aren't displayed in the order
in which they were created.  In other words, if I create 4 new windows,
then select window #1 to come up, I would expect to see the titles of
win1, win2, win3, win4 displayed.  Instead, I get win1, win4, win3, win2.
I've tested this out a bit more, and it seems that the nextWindow points
to the window underneath the current window, not the window that was created
after the current window.

This makes sense, but it doesn't help me out.  What I was going to do was
have a counter.  If menu item #2 was selected, then that must mean that
the second window needs to be topped.  I would then imcrement the window
pointer to the second created window and select it.  Obviously this will
not work.

So right now I'm thinking about creating an array holding the window pointers
and it would look something like this:

menuItem = 2;  // The third window needs to be topped

winPtr = ourArray[ menuItem ];

SelectWindow( winPtr );


I was wondering: Is there an easier (and more standardised) way of doing
this?  Are there any code examples of this floating around?


P.S.  I have thought about comparing the string in the menu item with the
title of the window.  The problem is this:  What do you do if you have
two windows with the same title?  Suppose you have two files from two
different folders opened with the same name?  I know that some apps add a
number at the end of the name (MyDoc:1 vs MyDoc:2), but personally, I
don't like doing that.


+++++++++++++++++++++++++++

>From [e-mail] (Bob Bradley)
Date: Tue, 30 Aug 1994 02:03:58 -0800
Organization: SS Software Inc.

In article <342f5e$[e-mail]>, [e-mail]
(Jeff Beeghly) wrote:

> I was digging through THINK Reference and I found out that a Window
> Record contains a pointer to the next window.  Well, I implemented a test
> into my program that displays the title of each child window:
>
> i = 0;
> whichWindow = FrontWindow();
> while( whichWindow )
> {
>         GetWTitle(whichWindow, title);
>         MoveTo(4, 10 + i);
>         DrawString(title);
>         whichWindow = (WindowPtr )(((WindowPeek )whichWindow)->nextWindow);
>         i += 20;
> }
>
> I'm comming across 2 problems with this:
> 1) In my app, if I create 4 new windows, then invoke this operation, only
> the top window's (window #4) title is displayed.  However, if I click on
> one of the other windows (causing the window to be moved to the front),
> then invoke this function, all four titles appear.  Thus, if I was to use
> this implementation of getting a list of windows, it wouldn't be valid
> until one of the windows was topped.

One probably you may be having is you may be drawing in a part of the
window that isn't visible so it's not showing up. Accessing the nextWindow
field of the WindowRecord doesn't select the window. Try moving your
windows apart so you know the part you are trying to draw into is visible
(normally you would always do any drawing from your updateEvt handler.).

> 2) Even when the items are displayed, they aren't displayed in the order
> in which they were created.  In other words, if I create 4 new windows,
> then select window #1 to come up, I would expect to see the titles of
> win1, win2, win3, win4 displayed.  Instead, I get win1, win4, win3, win2.
> I've tested this out a bit more, and it seems that the nextWindow points
> to the window underneath the current window, not the window that was created
> after the current window.

You are correct, nextWindow points to the window beneath the current
window. You can use this to step down thru your windows one beneath the
other.

> This makes sense, but it doesn't help me out.  What I was going to do was
> have a counter.  If menu item #2 was selected, then that must mean that
> the second window needs to be topped.  I would then imcrement the window
> pointer to the second created window and select it.  Obviously this will
> not work.

There is an example of keeping track of windows in a menu in the book Mac
Programming Secrets (Keith Rollin and Scott Knaster) and the source is
available almost everyway (usually named MPS 1.0.1). They keep track of
the order which the windows were created and access the windows via menus
in the same manner.

Another way you could do it is to attach some private data to the window
that contains a variable to keep track of which menuItem # the window goes
with, then write a simple routine to step thru the window list (using
nextWindow) checking each window's private data for the menuItem # you're
trying to find.

+++++++++++++++++++++++++++

>From Matt Slot <[e-mail]>
Date: 1 Sep 1994 01:43:11 GMT
Organization: University of Michigan

Jeff Beeghly, [e-mail] writes:
 > I was wondering: Is there an easier (and more standardised) way of doing
 > this?  Are there any code examples of this floating around?

- ---------

I have just written such a beast. Here is some sample code that handles
a windows menu. The default menu looks like this...

    Windows
    --------------------
    Show/Hide Floater #1
    Show/Hide Floater #2

And I add a separator when I put any document windows underneath.
Basically, I keep a Mac Queue of window information, that is ordered by
window creation. As I make, destroy, or rename a window, I make the
appropriate call and I am magically taken care of. I map the index of the
menu item into the element of the queue.

Share and enjoy

Matt

// * **************************************************************************** * //
// * **************************************************************************** * //
// Menu Item numbers

#define    kWindowsFloater1        1
#define    kWindowsFloater2        2
#define    kWindowsSeparator1        3

// * **************************************************************************** * //

typedef struct WindowQElem {
    struct WindowQElem qLink;
    short qType;
    WindowPtr win;
    } WindowQElem, *WindowQElemPtr;

// * **************************************************************************** * //

QHdr gDocsOpen;

// * **************************************************************************** * //

void AddToWindowsMenu(WindowPtr win) {
    Str255 textBuff;
    MenuHandle theMenu;
    WindowQElemPtr wQPtr;

    theMenu = GetMenu(kWindowsMenuID);
    if (CountMItems(theMenu) < kWindowsSeparator1)
        InsMenuItem(theMenu, "\p-", kWindowsSeparator1);

    if (wQPtr = (WindowQElemPtr) NewPtrClear(sizeof(*wQPtr))) {

        wQPtr->win = win;
        Enqueue((QElemPtr) wQPtr, &gDocsOpen);

        AppendMenu(theMenu, "\p ");
        GetWTitle(win, textBuff);
        SetItem(theMenu, CountMItems(theMenu), textBuff);

        DrawMenuBar();
        }
    }

// * **************************************************************************** * //
// * **************************************************************************** * //

void ModifyFromWindowsMenu(WindowPtr win) {
    short i;
    Str255 textBuff;
    MenuHandle theMenu;
    WindowQElemPtr wQPtr;

    theMenu = GetMenu(kWindowsMenuID);

    for(wQPtr = (WindowQElemPtr) gDocsOpen.qHead, i=0; wQPtr;
            wQPtr = wQPtr->next, i++)
        if (wQPtr->win == win) {
            GetWTitle(win, textBuff);
            SetItem(theMenu, kWindowsFirstWinItem + i, textBuff);
            DrawMenuBar();

            return;
            }

    }

// * **************************************************************************** * //
// * **************************************************************************** * //

void RemoveFromWindowsMenu(WindowPtr win) {
    short i;
    Str255 textBuff;
    MenuHandle theMenu;
    WindowQElemPtr wQPtr;

    theMenu = GetMenu(kWindowsMenuID);

    for(wQPtr = (WindowQElemPtr) gDocsOpen.qHead, i=0; wQPtr;
            wQPtr = wQPtr->next, i++)
        if ((wQPtr->win == win) && ! Dequeue((QElemPtr) wQPtr, &gDocsOpen)) {
            DelMenuItem(theMenu, kWindowsFirstWinItem + i);
            if (CountMItems(theMenu) == kWindowsSeparator1)
                DelMenuItem(theMenu, kWindowsSeparator1);
            DrawMenuBar();

            return;
            }
    }

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Thu, 01 Sep 1994 14:55:32 +0200
Organization: Royal Institute of Something or other

In article <342f5e$[e-mail]>,
[e-mail] (Jeff Beeghly) wrote:

>whichWindow = FrontWindow();
>while( whichWindow )
>{
>    GetWTitle(whichWindow, title);
>    MoveTo(4, 10 + i);
>    DrawString(title);
>    whichWindow = (WindowPtr )(((WindowPeek )whichWindow)->nextWindow);
>    i += 20;
>}

This looks quite allright.

>1) In my app, if I create 4 new windows, then invoke this operation, only
>the top window's (window #4) title is displayed.  However, if I click on
>one of the other windows (causing the window to be moved to the front),
>then invoke this function, all four titles appear.  Thus, if I was to use

This is strange. You're probably doing something wrong in
creating and showing the windows. Or maybe you're now showing
the windows? FrontWindow() returns the frontmost VISIBLE
window. If you want to get the list of ALL windows, you have to
use LMGetWindowList() and walk from there.

>2) Even when the items are displayed, they aren't displayed in the order
>in which they were created.  In other words, if I create 4 new windows,
>then select window #1 to come up, I would expect to see the titles of
>win1, win2, win3, win4 displayed.  Instead, I get win1, win4, win3, win2.

Yes; the titles come up in the order they lie in the layers. If
you create each new window on top of the preceeding window,
it'll be before it in the list.

Cheers,

                / h+


--
  Jon W‰tte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

  Reality exists only in your imagination.


---------------------------

>From [e-mail] (Chris DeSalvo)
Subject: SetDialogDefaultItem real?
Date: Wed, 17 Aug 1994 08:28:47 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Think Reference mentions two traps:

SetDialogDefaultItem and
SetDialogCancelItem

They are supposed to take care of button hiliting, outlining, and
keyboard mapping of things like return/enter and escape.

The traps are definied in the Universal Headers but they don't seem to
work.  They are not documented in the Dialog Manager section of
NIM:Toolbox Essentials.

Are these entries just place holders or is there some magic I have not
learned to get them to work?


Thanx
Chris
--
+-----------------------------------------------------------------+
| [e-mail]           |   Macintosh:  Changing the world, |
| Chris De Salvo              |        one person at a time!      |
| Professional Mac Geek       |    -----------------------------  |
| for MacPlay, Inc.           |      (I wish they'd hurry up!)    |
+-----------------------------------------------------------------+

Any opinions expressed, or implied, are my own!  They should not be
considered representative of the opinions or policies of my employer,
MacPlay, a division of Interplay Productions, Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Spencer Low)
Date: Wed, 17 Aug 1994 12:24:56 -0800
Organization: LowTek Creations

In article <[e-mail]>, [e-mail] (Chris DeSalvo)
wrote:
> The traps are definied in the Universal Headers but they don't seem to
> work.  They are not documented in the Dialog Manager section of
> NIM:Toolbox Essentials.

Make sure that you don't have an extension that messes with ModalDialog
filter procs - I was running the cool Escapade, but it seemed to stop this
"default" behavior.

If you have your own custom filter proc, make sure it calls the Standard
proc with GetStdFilterProc().

Spencer (please correct me if I'm wrong..)

+++++++++++++++++++++++++++

>From [e-mail] (Chris DeSalvo)
Date: Thu, 18 Aug 1994 11:03:40 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Spencer Low ([e-mail]) wrote:
: In article <[e-mail]>, [e-mail] (Chris DeSalvo)
: wrote:
: > The traps are definied in the Universal Headers but they don't seem to
: > work.  They are not documented in the Dialog Manager section of
: > NIM:Toolbox Essentials.

: If you have your own custom filter proc, make sure it calls the Standard
: proc with GetStdFilterProc().

That is probably the case, I do indeed have a custom event filter on
this dialog.  I will check it out.

Thanx
Chris
--
+-----------------------------------------------------------------+
| [e-mail]           |   Macintosh:  Changing the world, |
| Chris De Salvo              |        one person at a time!      |
| Professional Mac Geek       |    -----------------------------  |
| for MacPlay, Inc.           |      (I wish they'd hurry up!)    |
+-----------------------------------------------------------------+

Any opinions expressed, or implied, are my own!  They should not be
considered representative of the opinions or policies of my employer,
MacPlay, a division of Interplay Productions, Inc.

+++++++++++++++++++++++++++

>From Chris Anthes <[e-mail]>
Date: Thu, 18 Aug 1994 17:25:43 GMT
Organization: DSEA

In article <[e-mail]> Chris DeSalvo, [e-mail]
writes:
>: If you have your own custom filter proc, make sure it calls the Standard
>: proc with GetStdFilterProc().
>
>That is probably the case, I do indeed have a custom event filter on
>this dialog.  I will check it out.

Even if you are using a custom dialog filter, you can still use
SetDialogDefaultItem, SetDialogCancelItem, and SetDialogTrackCursor.
After you are done processing whatever you need to in your filter, make a
call to the Standard Dialog Filter.  This is all explained in detail in
Mac Tech Note #304.  Here is the code I use to handle custom dialog
filters.  This code differs slightly because I use returnVal to determine
whether or not I need to call the standard dialog routines.  I did this I
think because I needed to filter Return & Enter and alias them to Tab when
all of the data in my dialog wasn't entered (e.g. OK button grayed out).

/***** myDialogFilter *****/

pascal Boolean    myDialogFilter( DialogPtr theDialog, EventRecord
        *theDialogEvent, short *theDialogItem )
{
    ModalFilterProcPtr        standardProc;
    Boolean                    returnVal = false;
    WindowPtr                temp;

    //
    // Do all of your filter processing here...
    //

    // Go to the standard dialog filter if the event wasn't completely
    // handled
    if ( returnVal != true ) {
        GetPort( &temp );
        SetPort( theDialog );
        GetStdFilterProc( &standardProc );
        returnVal = ((ModalFilterProcPtr)standardProc)( theDialog,
            theDialogEvent, theDialogItem );
        SetPort( temp );
    }

    return( returnVal );
}

If you need some more info on this, send me an email.

Cya L8r,

Chris

***************************************************************************
*                             *                                           *
*  It's not the crime,        *  Chris Anthes          ([e-mail])  *
*  It's not the thought,      *  ---------------------------------------  *
*  It's not the deed,         *  DAINIPPON SCREEN ENGINEERING OF AMERICA  *
*                             *  3700 West Segerstrom Avenue              *
*  IT'S IF YOU GET CAUGHT!!!  *  Santa Ana, CA 92704                      *
*                             *                                           *
***************************************************************************

+++++++++++++++++++++++++++

>From [e-mail] (Brian Clark)
Date: Wed, 17 Aug 1994 11:00:34 -0500
Organization: Northwestern University

In article <[e-mail]>, [e-mail] (Chris
DeSalvo) wrote:

> Think Reference mentions two traps:
>
> SetDialogDefaultItem and
> SetDialogCancelItem
>
> Are these entries just place holders or is there some magic I have not
> learned to get them to work?

They work fine, but only when the standard system dialog filter proc is
called (either because you haven't specified your own, or you explicitly
call it from within your custom filter proc.

+++++++++++++++++++++++++++

>From [e-mail] (Andrew Southwick)
Date: 19 Aug 1994 14:02:53 GMT
Organization: IBM SWSD, Lexington, KY, USA

[e-mail] (Brian Clark) writes:
> [e-mail] (Chris DeSalvo) wrote:
>> SetDialogDefaultItem and
>> SetDialogCancelItem

>They work fine, but only when the standard system dialog filter proc is
>called (either because you haven't specified your own, or you explicitly
>call it from within your custom filter proc.

Also, these traps have to be defined by the headers that you are using.
The headers that come with ThinkC up til (at least) 6.0 don't define
them, so you have to do one of those
    void SetDialogDefaultItem( blah ) 0xYYYY;
things at the top of your code.  Sorry, don't have the trap number with me.
It's mentioned in the ThinkC Programming Primer, though, and ThinkRef
might have the trap numbers, too.


Best Premises,                                      [e-mail]
Andrew R. Southwick                                 [e-mail]


+++++++++++++++++++++++++++

>From Dave Falkenburg <[e-mail]>
Date: Thu, 1 Sep 1994 16:52:43 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]> Chris DeSalvo, [e-mail]
writes:
>SetDialogDefaultItem and
>SetDialogCancelItem
>
>The traps are definied in the Universal Headers but they don't seem to
>work.  They are not documented in the Dialog Manager section of
>NIM:Toolbox Essentials.

They were documented in the Technotes, but do to a race condition were never
included with IM:Toolbox Essentials. During the PowerPC effort, we figured
this out and added them to the headers.

>Are these entries just place holders or is there some magic I have not
>learned to get them to work?

Yes they work, but you must supply a dialog filter proc which calls
StdFilterProc in order to make them work as advertised. See technote
TB 37 "Pending Update Perils".

Whenever using modal dialogs it is best to always supply a filter proc
to keep pending updates in your application from blocking background
processing. The same technote which documents these calls explains this
problem in more detail.

Watch for an upcomming issue of MacTech, which will include "Sprocket",
an application shell with code that deals with these calls.

-Dave Falkenburg
-Apple Computer, Inc.

---------------------------

>From Bernd Mathiske <[e-mail]>
Subject: Stack sniffer - how can I turn it off?
Date: 16 Aug 1994 18:02:53 GMT
Organization: Universitaet Hamburg

Dear internet-community!

Help!
Do you know how I can get rid of the very annoying vbl-"stack sniffer"
that causes error #28 when I move the stack pointer into the heap?
I do not see the point why I should not have my stacks allocated
where I like them to be, in particular if there are several of them
between which I want to switch around, the latter allowing me to
implement coroutines.

Any idea anybody?

%  ======================================================
%                Bernd Mathiske
%  voice:        +49-40/54715-330
%  e-mail:       [e-mail]
%  snail mail:   Universitaet Hamburg
%                Vogt-Koelln-Strasse 30
%                D-22527 Hamburg, Deutschland
%  ======================================================

+++++++++++++++++++++++++++

>From [e-mail] (Eric Bowman)
Date: 17 Aug 1994 04:24:16 GMT
Organization: Reed College,  Portland, Oregon

In article <32qv0d$[e-mail]>,
Bernd Mathiske  <[e-mail]> wrote:
>Do you know how I can get rid of the very annoying vbl-"stack sniffer"
>that causes error #28 when I move the stack pointer into the heap?
>I do not see the point why I should not have my stacks allocated
>where I like them to be, in particular if there are several of them
>between which I want to switch around, the latter allowing me to
>implement coroutines.

To disable the stack sniffer,

Ptr oldTopOfStack = LMGetStackLowPoint();
LMSetStackLowPoint(NULL);

To undo the damage,

LMSetStackLowPoint(oldTopOfStack);

cheers,
bobo

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Wed, 17 Aug 1994 17:20:16 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <32qv0d$[e-mail]>, Bernd Mathiske
<[e-mail]> wrote:

>Do you know how I can get rid of the very annoying vbl-"stack sniffer"
>that causes error #28 when I move the stack pointer into the heap?
>I do not see the point why I should not have my stacks allocated
>where I like them to be, in particular if there are several of them
>between which I want to switch around, the latter allowing me to
>implement coroutines.

No it won't (:  There are problems with putting the stack in the heap,
specifically a number of toolbox calls expect the stack to be above the
heap and get very upset when it isn't.  If you want to do co-routines, use
the Thread Manager.

btw You can disable the stack sniffer by putting 0 into the low memory
global StkLowPt.  I've also seen Apple code that disables it by patching
SysError and preventing error 28 getting through (:
--
Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia

+++++++++++++++++++++++++++

>From [e-mail] (Ari I Halberstadt)
Date: Wed, 17 Aug 1994 17:54:25 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <[e-mail]>,
Quinn "The Eskimo!" <[e-mail]> wrote:
>In article <32qv0d$[e-mail]>, Bernd Mathiske
><[e-mail]> wrote:
>
>>Do you know how I can get rid of the very annoying vbl-"stack sniffer"
>>that causes error #28 when I move the stack pointer into the heap?
>>I do not see the point why I should not have my stacks allocated
>>where I like them to be, in particular if there are several of them
>>between which I want to switch around, the latter allowing me to
>>implement coroutines.
>
>No it won't (:  There are problems with putting the stack in the heap,
>specifically a number of toolbox calls expect the stack to be above the
>heap and get very upset when it isn't.  If you want to do co-routines, use
>the Thread Manager.

You can fool them into being happy by setting 3 low-memory globals.
It's tricky though.
--
Ari Halberstadt                                 [e-mail]
One generation passes away, and another generation comes: but the
earth abides for ever. -- Ecclesiastes, 1:4.

+++++++++++++++++++++++++++

>From [e-mail] (Sean Parent)
Date: Wed, 17 Aug 1994 22:48:18 GMT
Organization: Adobe Systems Incorporated

It is tricky to fool the toolbox because one of the lowmem globals that
has to be set is the HiHeapMark (thus confusing the memory manager). The
cleanest way (other than using the Thread Manager) that I have seen is to
just BlockMoveData your alternate stacks into the stack. It costs a few
extra cycles but can save you a boat load of time getting other stuff
working.

In article <[e-mail]>, [e-mail] (Ari I
Halberstadt) wrote:

> In article <[e-mail]>,
> Quinn "The Eskimo!" <[e-mail]> wrote:
> >In article <32qv0d$[e-mail]>, Bernd Mathiske
> ><[e-mail]> wrote:
> >
> >>Do you know how I can get rid of the very annoying vbl-"stack sniffer"
> >>that causes error #28 when I move the stack pointer into the heap?
> >>I do not see the point why I should not have my stacks allocated
> >>where I like them to be, in particular if there are several of them
> >>between which I want to switch around, the latter allowing me to
> >>implement coroutines.
> >
> >No it won't (:  There are problems with putting the stack in the heap,
> >specifically a number of toolbox calls expect the stack to be above the
> >heap and get very upset when it isn't.  If you want to do co-routines, use
> >the Thread Manager.
>
> You can fool them into being happy by setting 3 low-memory globals.
> It's tricky though.
> --
> Ari Halberstadt                                 [e-mail]
> One generation passes away, and another generation comes: but the
> earth abides for ever. -- Ecclesiastes, 1:4.

--
Sean Parent
[e-mail]
"The critical driver of every successful project is its focused ruthlessness."
        Grady Booch

+++++++++++++++++++++++++++

>From [e-mail] (Ari I Halberstadt)
Date: Thu, 18 Aug 1994 03:00:21 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <[e-mail]>,
Sean Parent <[e-mail]> wrote:
>It is tricky to fool the toolbox because one of the lowmem globals that
>has to be set is the HiHeapMark (thus confusing the memory manager). The
>cleanest way (other than using the Thread Manager) that I have seen is to
>just BlockMoveData your alternate stacks into the stack. It costs a few
>extra cycles but can save you a boat load of time getting other stuff
>working.

There is a third solution. It is very similar to the Thread Manager,
but has context switch times from over 2 to nearly 4 times faster than
the Thread Manager. It's my free Thread Library (not to be confused
with Apple's ThreadsLib). It's called ThreadLib-10d4.hqx (or some
similar name, depending on the archive), includes full source code,
and is available from info-mac mirrors in the dev/src directory, and
from the alt.sources.mac archive. I tested it under emulation on a
PowerPC, and it ran fine. It has been tested on a Plus, Quadra 950,
and PowerPC, with systems 6.0.5, 7Pro, and whatever the PowerPC needed
(7.1.1, or something like that). My Thread Library does not run
in native PPC mode, and does not support preemptive threads.
--
Ari Halberstadt                                 [e-mail]
One generation passes away, and another generation comes: but the
earth abides for ever. -- Ecclesiastes, 1:4.

+++++++++++++++++++++++++++

>From Clinton Bauder <[e-mail]>
Date: Tue, 23 Aug 1994 19:28:07 GMT
Organization: Apple Computer Inc.

In article <32qv0d$[e-mail]> Bernd Mathiske,
[e-mail] writes:
>Do you know how I can get rid of the very annoying vbl-"stack sniffer"
>that causes error #28 when I move the stack pointer into the heap?
>I do not see the point why I should not have my stacks allocated
>where I like them to be, in particular if there are several of them
>between which I want to switch around, the latter allowing me to
>implement coroutines.
>
>Any idea anybody?

You should use the Thread Manager if you can.  If you can't - say your
code is a driver or something - then you can disable the Stack Sniffer by
clearing the low memory global StkLowPt (0x110 - 32 bits).  Of course
when you are done using your private stack you should put it back to what
it was.  Also your stack should be at least 4K in size plus whatever you
expect to use in your own code.  This should be sufficient for most
interrupt code which might end up using your stack.  Note that this is
not the worlds most forward compatible kind of programming but if you can
accept the possibility of future incompatibility then this is a useful
technique.

Clinton
- -------------------------------------------------------------
Clinton Bauder        | Opinions expressed are very likely to
SCSI Grunt and Chief  | be entirely different from the official
Herpetoculturist      | party line of Apple Computer Inc.
Apple Computer Inc.   | Support your local herp society.
- -------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Ari I Halberstadt)
Date: Wed, 24 Aug 1994 01:37:38 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <[e-mail]>,
Clinton Bauder  <[e-mail]> wrote:
>it was.  Also your stack should be at least 4K in size plus whatever you
>expect to use in your own code.  This should be sufficient for most
>interrupt code which might end up using your stack.  Note that this is

Actually, you want at least MinStack bytes, plus whatever your app
will need. MinStack is a low-mem global.


--
Ari Halberstadt                                 [e-mail]
One generation passes away, and another generation comes: but the
earth abides for ever. -- Ecclesiastes, 1:4.

+++++++++++++++++++++++++++

>From Dave Falkenburg <[e-mail]>
Date: Wed, 31 Aug 1994 16:44:55 GMT
Organization: Apple Computer, Inc.

In article <32qv0d$[e-mail]> Bernd Mathiske,
[e-mail] writes:
>Dear internet-community!
>
>Help!
>Do you know how I can get rid of the very annoying vbl-"stack sniffer"
>that causes error #28 when I move the stack pointer into the heap?
>I do not see the point why I should not have my stacks allocated
>where I like them to be, in particular if there are several of them
>between which I want to switch around, the latter allowing me to
>implement coroutines.
>
>Any idea anybody?

The stack sniffer can be turned off by zeroing out STKLOWPT. However, this
isn't enough to keep the Macintosh working if you plan on calling the
toolbox from your coroutines.

The supported way of doing coroutines on the Macintosh is to use the
Thread Manager. The Thread Manager is available in the form of an
extension for System 7.0 or later, and has been rolled into the base
system software in System 7.5.

The current version of the extension is 2.0.1, which includes support for
PowerPC machines.

-Dave Falkenburg
-Apple Computer, Inc.

---------------------------

End of C.S.M.P. Digest
**********************